Push hugging face storage resolution into vortex-cloud rather than vortex-python - #9199

…e registry

Vortex could not read from the Hugging Face Hub. `hf://` was understood only by
`vortex.datasets`, which parsed the URI in Python and rewrote it into an
authenticated `HTTPStore`, so `vx.open("hf://...")` failed and Polars, DuckDB and
DataFusion could not open Hub URLs at all.

A Hub repository is a set of files behind an HTTP endpoint that honours range
requests, so serving one needs no cloud SDK: an `object_store::http::HttpStore`
rooted at the repository's `resolve` prefix, carrying a bearer token when one is
available, is the whole implementation. Reads therefore keep every
`ClientOptions` setting a caller passes -- timeouts, retries, proxy
configuration, `allow_http` -- unlike the OpenDAL-backed schemes, whose bridge
owns its own HTTP client.

Unlike every other scheme in the registry, the store is rooted at a
(repository, revision) pair rather than at the URL authority, since both occupy
URL path segments. It therefore reports the in-repository path itself and lets
the registry mount it that deep; getting this wrong would send the repository
name to the Hub as part of the file path, so it is covered from both the
build-and-cache and the cached-store branch.

Listing is not supported. The Hub does not implement WebDAV `PROPFIND`, which is
how `object_store`'s HTTP store lists a prefix. Opening a known path -- `head`
plus ranged `get`, both plain HTTP -- is what a Vortex scan needs, and callers
that must expand a glob can list through the Hub's own API first.

The `hf` feature adds no cloud SDK, only `http` and `percent-encoding`, so
`vortex-python` enables it unconditionally rather than making it opt-in the way
`opendal` is.

Towards #5379.

Signed-off-by: Robert Kruszewski <robert@spiraldb.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lc5zw7Le2T3pakDEUdKTYd

…x.open`

`vortex.datasets` still hand-built a Hugging Face `resolve` URL and an
authorization header for the two cases an `hf://` URI cannot express: a token
held in a variable, and a read that must stay anonymous despite the environment
offering credentials. Expose the store class those cases actually want.

`HfStore(repo_id, *, repo_type, revision, token, endpoint)` wraps the `HfConfig`
/ `make_hf_store` pair the way `CosStore` wraps `CosConfig`. `token` follows
`huggingface_hub`'s own convention, so a caller can pass its value straight
through: `None`/`True` take whatever the environment offers, `False` forces an
anonymous read, and a string is used directly. `revision` is passed literally --
unlike in a URL, the store percent-encodes a revision containing `/` itself.

`vx.open` previously accepted only the `pyo3-object_store` classes, which is why
`datasets.py` carried a comment that `CosStore` could not be read from. It now
takes the same `AnyVortexStore` extraction `read_url`/`write` use, so `HfStore`
works there -- and `CosStore` does too, removing that limitation.

Two things this surfaced:

* `HfConfig` built `ClientOptions::default()`, ignoring `ALLOW_HTTP`. Every other
  scheme picks it up because `parse_url_opts` reads its configuration from the
  environment, so a plain-HTTP `HF_ENDPOINT` -- a self-hosted Hub, or a test
  double -- behaved inconsistently. It is honoured now, which is what lets the
  new end-to-end read test exercise the real path against a local server.
* `HfRepoType` gained `FromStr` so the binding can take `repo_type="dataset"`,
  accepting the plural the Hub spells in its URLs as well.

With the store class in place, `datasets.py` no longer knows the Hub endpoint at
all: the `huggingface_hub.constants` import and the last `HTTPStore` use are gone.

Signed-off-by: Robert Kruszewski <robert@spiraldb.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lc5zw7Le2T3pakDEUdKTYd